csndfandomcom-20200214-history
Interaction Diagrams
Interaction diagram is a generalization of two more specialized UML diagram types. Both can express similar interactions. * Sequence diagrams * Communication diagrams Sequence diagrams are the more notationally rich of the two types, but communication diagrams have their use as well, especially for wall sketching. Interaction Diagram Notation Interaction diagrams is made of //lifeline// boxes. They represent the //participants// in the interaction. This can be an anonymous or named instance of class Sale or an instance of ArrayList The standard UML syntax for message expressions are return = message(parameter : parameterType) : returnType // For example initialize(code) initialize d = getProductDescription(id) d = getProductDescription(id:ItemID) d = getProductDescription(id:ItemID) : ProductDescription Parentheses are usually excluded if there are no parameters. Type information may be excluded if obvious or unimportant. If the //Singleton// pattern is used, the object is marked with a '1' in the upper right corner of the lifeline box. It implies that the Singleton pattern is used to gain visibility to the object. Sequence Diagram Notation Lifeline: In sequence diagrams the lifeline boxes include a lifeline extending below them. These may be solid or dashed. **Messages:** Each (typical synchronous) message between objects is represented with a message expression on a filled-arrowed solid line between the vertical lifelines. The starting message is called a //found message//, shown with an opening solid ball. It implies that the sender will not be specified, is not known, or that the message is coming from a random source. **Execution specification bar:** (previously called an activation bar.) Shows the focus of control. It represents the time the object is "active", i.e. doing some processing, computing something, waiting for a response from a sub-routine, etc. Drawing the bar is more common when using a UML CASE tool, and less common when wall sketching. **Returns:** There are two ways to show the return result from a message: * Using the message syntax returnVar = message(parameter). When sketching, this is less effort. * Using a reply (or return) message line at the end of an activation bar with a description of the returning value. **Messages to 'self':** You can show a message being sent from an object to itself by using a nested activation bar. The message will point back at the owner object. **Creation of instances:** Object creation is shown with a dashed line. The arrow is filled if it's a regular synchronous message, or open if an asynchronous call. The message name create is not required, but it's a UML idiom. The newly created object are placed at their creation "height". **Object destruction:** In some circumstances it is desirable to show explicit destruction of an object. E.g. when no garbage collection, or when you want to especially indicate an object is no longer usable (such as a closed database connection). This is expressed with the «destroy» message, with the large X and short lifeline. **Condition/loop:** To support conditional and looping constructs (among many other things), the UML uses //frames//. They have an operator or label (such as "loop") and a guard (conditional clause). The guard should be placed over the lifeline to which it belongs. ^ Frame Operator ^ Meaning ^ | alt | Alternative fragment for mutual exclusion conditional logic expressed in the guards. | | loop | Loop fragment while guard is true. Can also write //loop(n)// to indicate looping n times. | | opt | Optional fragment that excludes if guard is true. | | par | Parallel fragments that execute in parallel. | | region | Critical region within which only one thread can run. | **Iterate over a collection:** Use a //selector// expression, e.g. lineItemsi, in the lifeline. This is used to select one object from a group. Lifeline participants should represent one object, not a collection. **Relate interaction diagrams:** An //interaction occurence// is a reference to an interaction within another interaction. It's useful when you want to simplify a diagram and factor out a portion into another diagram, or there is a reusable interaction occurrence. They are created with two related frames: * A frame around an entire sequence diagram, labeled with the tag //sd// and a name, such as AuthenticateUser. * A frame tagged //ref//, called a //reference//, that refers to another named sequence diagram. //Interaction overview diagrams// also contain a set of reference frames (interaction occurrences). These diagrams organized references into a larger structure of logic and process flow. Any sequence diagram can be surrounded with an //sd// frame, to name it. Frame and name one when you want to refer to it using a //ref// frame. **Polymorphic messages:** These can be shown by using multiple sequence diagrams. One that shows the polymorphic message to the abstract superclass or interface object, and then separate sequence diagrams detailing each polymorphic case, each starting with a //found// polymorphic message. **Asynchronous calls:** These calls are used in multi-threaded environments so that new threads of execution can be created and initiated. In Java you may think of the Thread.start or Runnable.run (called by Thread.start) message as the asynchronous starting point to initiate execution on a new thread. The UML notation for this is a stick arrow message. References # Craig Larman, "Applying UML and Patterns", Ch.15 Category:Design